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15 December 1970 


MEMORANDUM FOR: Deputy Chief, OCS 


SUBJECT 


] Implementation Effort 


1 . 


This memorandum is a comprehensive review of the 
] Project to date. It will attempt to show why we are 


involved in 'front-ending'; the problems we have faced and 
are facing; the considerations involved in making certain 
critical decisions; our position now; and finally what direc- 
tion the | | project staff feels we should be taking. 


2. The Business of 'Front-Ending': 


Two very basic reasons for a front-end computer are 


1) to provide switching and 

2) to relieve the host processor of the burden of handling 
communications I/O. 

This latter reason manifests itself in several ways: 

1) Communications I/O causes an increased load on the 
central processor due to the number of interrupts 
generated. 

2) The software necessary to handle varying types of 
terminals is overly-complex. Furthermore, some 
types of terminals might be prohibited because of 
hardware restrictions and a lack of software to 
support them. 


3) Communications I/O causes a proliferation of trans- 
mission control units which are both costly and at 
any one point in time dedicated to a particular computer 


These problem areas are present in our computer center to 
varying degrees. 





RDP78-04723A0001 00060001 -9 


'■ ' v; i j'V? v ;Vi 5 , ■ ■ r i' r r . ■ ■ ; Jh 




SECRET 

Approved For Release 2002/06728 :CiA-RDP78-04723A0001 00060001 -9 



X ! 






A 



25X1 A 
25X1A 


■rr./ 


•\ I 


■r! 

ij 



We now have attached to the 360/67 one 2703, two 2701’s, 
and three 2848*8 to support the communications requirement to 
that machine. We expect it to increase. We are required 
to support various types of devices (2260's, 2741's, teletypes, 
1050's) in CP. We cannot implement other terminals unless 
they are compatible with the aforementioned types without 
modifying CP. We have two 2701's attached to 360/65-2 for 
RJE requirements. We have a 100K RJE program in the 65-2 
just to support RJE. We are supporting a remote requirement 
through a 9300 in Office of Communications. We have a large, 
though really undefined (estimates of 200 terminals have been 
given), terminal requirement for information retrieval purposes. 

There is a possible requirement to support o ffices remote 

from the center with OCS computers (IPRD, 9300 

This means more communications lines into our center. 


i 


I 


\ 

25X1 A 


These are the needs (some firm, other projected) that 
we can see today. More importantly, though, we feel that 
applications involving communications facilities will increase 
drastically rather than decrease. We feel that we will have 
real problems in the next five years coping with these applica- 
tions unless we start preparing now. 


3. What Happened: 


It was decided in OCS approximately 11/2 years ago to take 
a positive step towards meeting our future requirements by 
acquiring a front-end computer. After an initial selection 

]computer was brought in for te st and 
Somewhat before that time. 


process, a 


^project. 


evaluation in April 1970. 

I I was appointed project leader for the 

I I was also appointed to the team. Their respon- 

sibilities were to represent OCS on a design and implementation 
team composed of OCS and personnel. This team was to: 


25X1 
25X1 A 

25X1A 


1. Design and implement a communications interface 
to OS on the 360/65-2 for the purpose of bringing an RJE 
job stream into OS. 


2. Design and implement a communications interface 
to CP on the 360/67 to handle time-sharing terminals. 

2 
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A part of the system (hardware and software) that 
provides to its cust omers is a program called 


|which is designed to run in OS as a type IV 


SVC. This is an access method which provides programs running 
in OS macros to communicate with the l I processor. 

Through either a misunderstanding on the part of OCS in the 
initial selection or a misrepresentation by | | (it has never 

been clear which was the case) it was the impression of OCS that 
]would wor k for CP. Very early in the design effort it 

would not work for CP and that indeed the 
and CP would be a tremendous problem. 


developed that 
interfacing of 


The design and implementation effort, therefore, became two 
distinct problems, that of interfacing to OS and that of inter- 
facing to CP. 


4. Interfacing to OS: 


It was decided to utilize 


pVC in OS to bring in 


an RJE job stream. After considering the problem of how to 
use the SVC, it was decided to implement the interface on an 
OS reader and writer basis for the following reasons: 


1. The OS RJE program required 100K bytes of 
resident core which we felt was unnecessary. 

2. The reader/writer interface provides more flexi- 
bility for decision on what type of devices could be used 
as RJE terminals. 

3. The reader and writer interface would require 
less core than OS RJE since they are smaller and are 
transient. 

4. It was felt the reader and writer interface would 
be less version dependent. 

Accordingly, work was started on this type of interface. 
Detailed RJE specifications were drawn up jointly by I 
and OCS personnel with final specifications reviewed, agreed 
upon, and completed by mid-September 1970. A proposed 



3 



25X1 A 
25X1 A 


25X1 A 


!> 


25X1 A 


|| 

<b> 

iii 


\ ly 




25X1 A r 


y.'.i.' 


§ 


!» 

•M 


US 


& 


!:; ( 




I 


25X1Ai 


' >!■ 









Approved For Release 20 


78-04723A0001 00060001 -9 



schedule for soft ware coding , debugging and testing was drawn 

up and submitted I I Slippage occurred for the follow- 

ing reasons: 


!• Problems were encountered by 


in generating 


a Network Control Program (NCP) to meet the RJE specifi- 
cations. 


2. There were eight major hardware problems 
identified. 


3 . Th t e re were unanticipated problems in the complexity 

of the | [ interface in the OS writer. 

4. The timing problems using | | under CP made it 

necessary to do all our testing on block time with a dedi- 
cated machine. This greatly cut down the available number 
of test opportunities. 

5. The FMSAC 2780 terminal was available only on 
a sporadic basis. 


6. There were bugs in , 
the BSC handler was never properly tested byf 
before delivery. 


code. For example, 


7. There was a lack of knowledge about the proper 
2780 conventions. (This problem complicated pin-pointing • 
bugs in the BSC handler. ) 


8 * | ls very unstable. (An IPL of OS is necessary 

after running each test program to insure stable conditions). 


At present (11 Dec 70), the interface is still 
because of some minor problems in the I 1 


not complete 
system. 


The test period indicates that the present | | NCP inter- 
face is too uns table for the OCS environment. Solutions include 
re-writing the | I - NCP interface, a new interface or a combi- 
nation of both. 


4 
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5. Interfacing to CP: 


When it was learned (early June) that | | could provide 

no ready software to interface to CP, we began exploring alter- 
natives to solve the problem. Some of the ground rules we 
established were that it should not cost CP any increase in 
communications overhead and that modifications to CP should be 
kept to a minimum. We did not want to make CP any more 
version dependent than it already was. The two alternatives 
that emerged from our study were these: 


1) | would build a new Computer Interface 

Adapter (CIA) which would allow the | computer to 

be able to respond to 256 unique addresses on the OS 
multiplexor channel. This would enable software in the 
| l computer to emulate any 270X transmission control 

unit with no impact on host computer software, i. e. , 
existing channel programs within CP (or OS) would not need 
to be modified. We placed a 95% chance of success on this 
method. It would, however, cost OCS an additional 
$50, 000 to $100, 000. 


2) Software in the host computer system would have 
to be modified to communicate with the | computer 

over the existing CIA. This was in fact the method of 
attack we were already employing in the interface to OS. 
However, there we had the advantage in that | ~| was 
already written. In CP we estimated the software modifi- 
cations would take 6 to 9 man-months. In addition, another 
3 to 4 man-months would be necessary on the | ]side. 


We recommended alternative 1 above. It would result in a 
common interface to any IBM machine which has a communica- 
tions requirement and can support a 270X, and it would have the 
least impact on existing software. We further recommended a 
change in the contract for both money and time allocations to 
reflect this recommendation. 


While these activities were being carried on (OS interface 
testing and evaluating CP alternatives) many discussions were 
held with OCS management to review the decision to acquire 
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initially. Some people In OCS were disappointed in 
performance and the company's financial position. 


The obje ctions were very well stated in a memora ndum to Acting 
Director of Computer Serv ices, subject: I l dated 


— — * - 

8 October 1970, written byL 


then Chief of Operations 


O X.KJ A a. / i W # / I 1 , A 

Division. The arguments wilL not be summarized here. After 
much discussion, a recommendation was made by[^ 


mucn aiscuBBiyui — - ■ r— 

to re-negotiate the contract and continue develop mental work 
The contract was re-negotiated by [ 


and it called for the implementation of our previous recommen- 
dation. Some hardware initially contracted for was turned back 
lin order to pay for the construction of a new- CIA. as 

J ... .mi .1 1 a. 1 4-1 1 nrf rtf ^^40 . 000* 


to 


a result th e project is still under its initial funding of $340, 000. 


6. Projected Plans: 


The projected plan is summarized in an attachment to this 
memorandum. Although our new design goals under the revise 
contract are geared to present requirements of interfacing 
I 1 to the 360/65's using OS and the 360/67 using CP, the 

I I . _ i ^ ...S 4- Vi r\o 1 1 a! 


expected advent of future computer technology with parallel 
processing and an increased sensitivity to interrupts lends added 
weight to the concept of data concentration. In our proposed 
tasks we have, therefore, tried to be as flexible as possible in 
providing for both line and data concentration as well as Z70X 
transmission control unit emulation in the front-end processor. 
In the proposed systems design, both the capabilities of 270X 
emulation and a | | like interface (providing concentration 
capability) will be given equal weight. We will implement both 
in our design if it is at all possible. 


In general, the | [ development task as proposed has 

ree major breakdowns (see attachment): 


1) Preliminary design - 15 Dec 70 through 30 Jan 71 

2) Final detail design - 1 Feb 71 through 30 Apr 71 

3) Writing, testing - l May 71 through 29 Feb 72 


In the preliminary design area, we are attempting to define 
as many general system requirements as possible. One of the 
most important questions will be whether it is feasible and 
practical to do both 270X emulation and a | | »like interface 
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simultaneously. Another possible requirement will be message 
switching. We consider the ability to communicate among the 
various computers in our center to be an immediate and import- 
ant requirement. We will consider the feasibility of doing rolling 
and scrolling in the front-end processor. The 2260 code 
(assuming we still have 2260's) could be removed from CP. If 
we have some other CRT devices, the fact that the front-end 
could roll and scroll for them might mean that we could buy less 
sophisticated CRTs. Security requirements as well as recovery 
and/or backup will also be explored. 


In the final design phase, we will translate the general 
requirements arrived at into detailed systems design. Modules 
to be changed will be identified, requirements in detail will be 
specified, flow charts drawn and a time schedule for the third 
phase will be developed. 


At various points in phase 1 and phase 2 we will formally 
review our design with as many knowledgeable people from 
~| as possible. Arrangements have already been made 
for | | to provide consulting services. Furthermore, time 

has been left for formal education on | | software in phase 1. 


The third phase will be the actual writing and testing of 
software. We also hope to validate at this time many of the 
design goals which came out of phases 1 and 2. We do not 
believe that we will be exactly right in either the philosophy of 
the system or its details. What we do hope to accomplish is 
to contribute heavily to OCS's experience and body of knowledge 
in front- ending as well as providing some operational capability. 

Some of the more detailed changes which we can foresee 
at this time follow. Generally they fall in three areas: 

1) Computer interface- adapt er software to provide 

270X emulation as well as a I I type interface. 

2) | | systems tuning to enhance throughput. 

3) Line terminal handlers. 
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Computer Interface Adapter (CIA) Handler 


This handler, which is a part of the I [ supervisor, 

will either be completely rewritten or a module will be added 
to it to simulate those functions which are now handled by 270X 
control units. Some of these functions are: 


* Cyclic Redundancy Check, Vertical Redundancy Check 
and Longitudinal Redundancy Check 


* Status Responses 

Initial Select 
Commands 

* Line Addressing Capability 

* CCW Analysis 


Commands 


In addition, the handler will be modifi ed to d istinguish the 270X 

Jlike requests being 


requests from the 


___ "[ike requests. 

those which allow the host computer to concentrate data and 
block messages into one transmission across the channel opera- 
ting in subselector rather than multiplexor mode. Testing of 
current 


laccess method in the 360 indicates that present 
^provided 360 SVC and[ I NCP are too unstable 


for operational use. Proposed modifications would include modi- 
fications to the 360 SVC to make it look more like a standard OS 
access method, and to simplify channel checking procedures 
back and forth across the channel, reducing interrupt overhead 
and removing stringent packet restrictions and data restrictions. 
A | H ike access method added to OS would present a fairly 
comprehensive programming effort becaus e interru pts from 
more than one line presented as data from I I would have 

to be presented separately to OS so that they could be properly 
posted and handled. 


A number of modules in the Native Processor Support 
Routine (NPS) as part of NCP would have to be modified or re- 
written to properly interface with the new channel requirements. 
For the | | like interface, it is conceivable that the Background 
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Timing Routine (BGD) and Queue Update Routine (QUPD) would 
have to be modified to provide the ability to generate interrupts 
in order to transmit messages in large bursts to the host com- 
puters on either a time or size basis. For conversational type 
terminals with core queued messages, the Selection Routine which 
would be modified to scan core for full buffers to be transmitted 
to the host computer, would also incorporate some facility for 
interfacing to the CIA handler for purposes of transmitting blocks 
of messages when N number of buffers are full for any given computer 
Core Queue Management modules would also be modified. 

Prior to final systems specification, it will be necessary to 
determine the level at which the line handlers must operate and 
interface to NCP. This requirement is generated because of the 
need in conversational systems to not generate a new I/O command 
until the current I/O is actually complete at the terminal. In 
general, a host computer initiated I/O is complete once it is 
successfully transmitted across the channel to | ] but in 

terms of the problem program, it may not be complete until it 
has been transmitted to the terminal, where in a store and for- 
ward application, the I/O is obviously complete as soon as it is 
successfully received by | I 

Systems Enhancements to Improve Throughput 


A throughput analysis of the current configuration and system 
has shown that a number of modifications must be made to the 
system in order to provide the kind of throughput necessary to 
support our projected number of at least 200 terminals. This 
analysis considered conversational messages but did not consider 
RJE messages. RJE messages, because of their size, require 
an undetermined number of disk accesses. NCP currently 
handles data internally on a byte basis. We propose modifying 
NCP to process I/O on a block or word basis. Current NCP 
design provides for either core-queued or disk queued messages, 
but not both at the same time. We recognize the need for both 
types of queuing, i. e. , to core queue conversational type 
terminals, which have predictable maximum messages sizes, and 
to disk queue RJE type terminal messages, with varying message 
sizes. Core queuing is a necessity if we are to achieve the 
projected throughput. The following is an example of the types 
of throughputs currently attained and attainable in the system 
with modifications: j 

9 



Approved For Release 2002/06/28 



riS'Sl 







Approved For Release 20! 


'P78-04723A0001 00060001 -9 


* Standard NCP with 6108 (slow disk) queuing on I/O 
allows 18 msgs/sec. 

* Standard NCP with core queuing on input and 6108 
disk queuing on output allows 28 msgs/sec. 

* NCP with block or word processing, core queuing 
on input, 6108 disk queuing on output allows 

32 msgs/ sec. 

* NCP with block or word processing and core queuing 
on I/O allows 40 msgs/sec. 


These figures approach maximum throughput capability of 
a general purpose communications software package with the 
scope of NCP. It is probably possible to increase throughput 
capability by a special purpose package tailored to our needs. 

A portion of our development on this aspect will be the analysis 
of throughput capabilities of proposed modifications to 8 ^ e ^* 
Another study will consider the maximum achievable capabilities 
through complete rewrite, tailor-making a package to achieve 
maximum capability of hardware. 


Modules which have to be modified or rewritten are: 

1) The Mass Storage Queue modules to allow both core 
and disk queuing, 

2) The Core Queue Buffer Management Routine, 

3) The queuing modules which are entered upon 
scheduling transmission to allow NPS to provide messages 
from either core ox disk, 


4) Selection Routines to allow scan to select messages 
for transmission from core and from disk queues, 

5) The Queue Update routine, which appends or deletes 
sectors as messages are queued and dequeued, 

6) Line buffer handling modules must be modified to 
provide block or word processing. 
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Another systems enhancement would be the ability to select 
messages on a priority level for a limited number of lines. Cur- 
rently, the priority selection scheme requires priority selection 
for all lines if it is selected at all. In the case of user input from 
terminals, it might be nice to allow the user to input more than 
one line, such as when he is creating a new file, wherein his 
message would have to be disk queued rather than core queued 
while in input mode. Modifications would have to be made to 
a number of blocks and routines having to do with queuing so 
that the status of a terminal can be changed from conversational 
to nonconversational (disk queued). Current systems design only 
permits dyntabs, which describe the lines and line groups, to be 
modified at IPL time. We recommend that this be changed to 
dynamic modification through the operator console. This would 
probably entail the addition of a new operator function to the 
Command Module which is the module which accepts commands 
from the console and interfaces to the rest of the system. 

Line Terminal Handlers 

During the design period, we will endeavor to determine the 
types of line handlers which must be included in the system and 
make provision for providing them. 

It must be stressed that these time estimates and dates are 
only estimates and subject to change as conditions develop. 
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ATTACHMENT 


1. 15 Dec 70 - 30 Jan 71 Preliminary Design 


A. Required 2703 capability 

B. Preliminary consulting on the | | Time 

Sharing System and I I on NCP (Dec 14-18) 

C. Formal Education (Jan 4-9) 

D. Block Processing 

E. Core Queuing 

F. Feasibility of a | j like Interface in Conjunction with 

2703 Emulation 

G. Preliminary System Requirements for: 

Store and Forward 

Message Switching 

Real-Time Services 

Roll and Scroll 

Security Requirements 

Recovery or Back-up Requirements 


2. 1 Feb - 30 Apr 71 Final Detail Design 


A. MA/CIA Handler and Interfaces 

B. Modifications to Native Processor Support (NPS) 

C. I I CIA -- MA/CIA Relationship 

D. Block Processing 

E. Core Queuing 

F. Level of Operation and Interfaces of Line Handlers to the 

Remainder of NCP 

G. Other: Communication Interfaces 

9300 Interfaces 
ASP Interfaces 

H. Final Detail Specifications for Each Module (New or 

Modified) 

I. Time Schedule for Next Phase 


3. 1 May 71 - 29 Feb 72 Code, debug, comprehensive system 

testing, experimentation and valida- 
tion of design philosophies and re- 
quirements. 
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Remarks : 


The attached provides a status report on the 
[communications processor. Pardon 
the jargon, but the subject is rather technical. 
Summary: We have much work to do to get 
into productive use. 
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